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Abstract 
This document updates RFC 3312, which defines the framework for 
preconditions in SIP. We provide guidelines for authors of new 
precondition types and describe how to use SIP preconditions in 


situations that involve session mobility. 
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1. Introduction 


RFC 3312 [3] defines the framework for SIP [2] preconditions, which 
is a generic framework that allows SIP UAs (User Agents) to suspend 
the establishment of a session until a set of preconditions are met. 
Although only Quality of Service (QoS) preconditions have been 
defined so far, this framework supports different types of 
preconditions. (QOS preconditions are defined by RFC 3312 as well). 


This document updates RFC 3312, provides guidelines for authors of 
new precondition types and explains which topics they need to discuss 
when defining them. In addition, it updates some of the procedures 
in RFC 3312 for using SIP preconditions in situations that involve 
session mobility as described below. 


RFC 3312 focuses on media sessions that do not move around. That is, 
media is sent between the same end-points throughout the duration of 
the session. Nevertheless, media sessions established by SIP are not 
always static. 


SIP offers mechanisms to provide session mobility, namely re-INVITEs 
and UPDATEs [5]. While existing implementations of RFC 3312 can 
probably handle session mobility, there is a need to explicitly point 
out the issues involved and make a slight update on some of the 
procedures defined there in. With the updated procedures defined in 
this document, messages carrying precondition information become more 
explicit about the current status of the preconditions. 


Specifically, we now allow answers to downgrade current status values 
(this was disallowed by RFC 3312). We consider moving an existing 
stream to a new location as equivalent to establishing a new stream. 
Therefore, answers moving streams to new locations set all the 
current status values in their answers to "No" and start a new 
precondition negotiation from scratch. 


2. Terminology 


In this document, the key words "MUST", "MUST NOT", "REQUIRED", 
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 
described in BCP 14, RFC 2119 [1] and indicate requirement levels for 
compliant implementations. 
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3. Defining New Precondition Types 


Specifications defining new precondition types need to discuss the 
topics described in this section. Having clear definitions of new 
precondition types is essential to ensure interoperability among 
different implementations. 


3.1. Precondition Type Tag 


New precondition types MUST have an associated precondition type tag 
(e.g., "qos" is the tag for QoS preconditions). Authors of new 
preconditions MUST register new precondition types and their tags 
with the IANA by following the instructions in Section 15 of RFC 
3312. 


3.2. Status Type 


RFC 3312 defines two status types: end-to-end and segmented. 
Specifications defining new precondition types MUST indicate which 
status applies to the new precondition. New preconditions can use 
only one status type or both. For example, the QoS preconditions 
defined in RFC 3312 can use both. 


3.3. Precondition Strength 


RFC 3312 defines optional and mandatory preconditions. 
Specifications defining new precondition types MUST describe whether 
or not optional preconditions are applicable, and in case they are, 
what is the expected behavior of a UA on reception of optional 
preconditions. 


3.4. Suspending and Resuming Session Establishment 


Section 6 of RFC 3312 describes the behavior of UAs from the moment 
session establishment is suspended, due to a set of preconditions, 
until it is resumed when these preconditions are met. In general, 
the called user is not alerted until the preconditions are met. 


In addition to not alerting the user, each precondition type MUST 
define any extra actions UAs should perform or refrain from 
performing when session establishment is suspended. The behavior of 
media streams during session suspension is therefore part of the 
definition of a particular precondition type. Some precondition 


Camarillo & Kyzivat Standards Track [Page 3] 


RFC 4032 SIP Preconditions Framework March 2005 


types may allow media streams to send and receive packets during 
session suspension; others may not. Consequently, the following 
paragraph from RFC 3312 only applies to QoS preconditions: 


While session establishment is suspended, user agents SHOULD not 
send any data over any media stream. In the case of RTP, neither 
RTP nor RTCP packets are sent. 


To clarify the previous paragraph, the control messages used to 
establish connections in connection-oriented transport protocols 
(e.g., TCP SYNs) are not affected by the previous rule. So, user 
agents follow standard rules (e.g., the SDP ’setup’ attribute [7]) to 
decide when to establish the connection, regardless of QoS 
preconditions. 


New precondition types MUST also describe the behaviour of UAs on 
reception of a re-INVITE or an UPDATE with preconditions for an 
ongoing session. 


4. Issues Related to Session Mobility 


Section 5 of RFC 3312 describes how to use SIP [2] preconditions with 
the offer/answer model [4]. RFC 3312 gives a set of rules that allow 
a user agent to communicate changes in the current status of the 
preconditions to the remote user agent. 


The idea is that a given user agent knows about the current status of 
some part of the preconditions (e.g., send direction of the QoS 
precondition) through local information (e.g., an RSVP RESV is 


received indicating that resource reservation was successful). The 
UAC (User Agent Client) informs the UAS (User Agent Server) about 
changes in the current status by sending an offer to the UAS. The 


UAS, in turn, could (if needed) send an offer to the UAC informing it 
about the status of the part of the preconditions the UAS has local 
information about. 


Note, however, that UASs do not usually send updates about the 
current status to the UAC because UASs are the ones resuming 
session establishment when all the preconditions are met. 
Therefore, rather than performing an offer/answer exchange to 
inform the UAC that all the preconditions are met, they simply 
send a 180 (Ringing) response indicating that session 
establishment has been resumed. 
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While RFC 3312 allows updating current status information using the 
methods described above, it does not allow downgrading current status 
values in answers, as shown in the third row of Table 3 of RFC 3312. 
Figure 1 shows how performing such a downgrade in an answer would 
sometimes be needed. 


3pcc 
A Controller B € 


<-dialog 1->|<-dialog 2-> 
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<-dialog 1->|<------ dialog 3----- > 
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Figure 1: Session mobility using 3pcc 


The 3pcc (Third Party Call Control) [6] controller in Figure 1 has 
established a session between A and B using dialog 1 towards A and 
dialog 2 towards B. At that point, the controller wants A to have a 
session with C instead of B. To transfer A to C (configuration shown 
at the bottom of Figure 1), the controller sends an empty (no offer) 
re-INVITE to A. Since A does not know that the session will be 
moved, its offer in the 200 OK states that the current status of the 
media stream in the send direction is "Yes". After contacting C 
establishing dialog 3, the controller sends back an answer to A. 

This answer contains a new destination for the media (C) and should 
have downgraded the current status of the media stream to "No", since 
there is no reservation of resources between A and C. 


4.1. Update to RFC 3312 


Below is a set of new rules that update RFC 3312 to address the 
issues above. 
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The rule below applies to offerers moving a media stream to a new 
address: 


When a stream is being moved to a new transport address, the offerer 
MUST set all current status values about which it does not have local 
information about to "No". 


Note that for streams using segmented status (as opposed to end-to- 
end status), the fact that the address for the media stream at the 
local segment changes may or may not affect the status of 
preconditions at the remote segment. However, moving an existing 
stream to a new location, from the preconditions point of view, is 
like establishing a new stream. Therefore, it is appropriate to set 
all the current status values to "No" and start a new precondition 
negotiation from scratch. 


The updated table and rules below apply to an answerer that is moving 
a media stream. The offerer was not aware of the move when it 
generated the offer. 


Table 3 of RFC 3312 needs to be updated to allow answerers to 


downgrade current status values. The following table shows the 
result. 


Transac status table Local status table New values transac./local 


no no no/no 
yes yes yes/yes 
yes no depends on local info 
no yes depends on local info 


An answerer MUST downgrade the current status values received in the 
offer if it has local information about them or if the media stream 
is being moved to a new transport address. 


Note that for streams using segmented status, the address change at 
the answerer may or may not affect the status of the preconditions at 
the offerer’s segment. However, as stated above, moving an existing 
stream to a new location, from the preconditions point of view, is 
like establishing a new stream. Therefore, it is appropriate to set 
all the current status values to "No" and start a new precondition 
negotiation from scratch. 


The new table below applies to an offerer that receives an answer 
that updates or downgrades its local status tables. 
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Offerers should update their local status tables when they receive an 
answer as shown in the following table. 


Transac. status table Local status table New value Local Status 


no no no 
yes yes yes 
yes no yes 
no yes no 


4.2. Desired Status 


The desired status that a UA wants for a media stream after the 
stream is moved to a new transport address may be different than the 
desired status negotiated for the stream originally. A UA, for 
instance, may require mandatory QoS over a low bandwidth link but be 
satisfied with optional QoS when the stream is moved to a high 
bandwidth link. 


If the new desired status is higher than the previous one (e.g., 
optional to mandatory), the UA, following RFC 3312 procedures, may 
upgrade its desired status in an offer or in an answer. If the new 
desired status is lower that the previous one (i.e., mandatory to 
optional), the UA, following RFC 3312 procedures as well, may 
downgrade its desired status only in an offer (i.e., not in an 
answer.) 


5. Security Considerations 


An attacker adding preconditions to a session description or 
modifying existing preconditions could prevent establishment of 
sessions. An attacker removing preconditions from a session 
description could force sessions to be established without meeting 
mandatory preconditions. 


Thus, it is strongly RECOMMENDED that integrity protection be applied 
to the SDP session descriptions. S/MIME is the natural choice to 
provide such end-to-end integrity protection, as described in RFC 
3261 [2]. 


6. IANA Considerations 
The IANA registration requirements for the preconditions framework 


are defined in RFC 3312. Any new preconditions are governed by the 
IANA Considerations there. 
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